Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix issue: #525: A race condition in styx object store. #537

Merged

Conversation

mikkokar
Copy link
Contributor

Fixes issue #525.

@mikkokar mikkokar changed the title Fix object store race condition. Fix issue: #525: A race condition in styx object store. Nov 21, 2019
Comment on lines 55 to 57
pendingChangeNotification.set(false)

issuedSnapshot = pendingSnapshot
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should these be protected by the lock? To prevent the possibility of a double notification of the same snapshot. Not a critical issue, admittedly.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The event dispatch always runs serially: They run in the single threaded executor.

However locking is necessary to guarantee the following invariant holds:

  • PendingChangeNotification == true only when issuedSnapshot < pendingSnapshot
  • PendingChangeNotification == false when issuedSnapshot >= pendingSnapshot

Clearly this invariant is not consistent in the event dispatch thread.

I will fix this.


issuedSnapshot = pendingSnapshot
watchers.forEach { watcher ->
watcher.invoke(newSnapshot(pendingSnapshot))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should probably be notifying with the issuedSnapshot rather than the pendingSnapshot.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, definitely!
Thanks for spotting this.

private val pendingChangeNotification = AtomicBoolean(false)
private val lock = ReentrantLock()

private val listeners = ConcurrentHashMap<String, DispatchListener<T>>()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are the listeners only for use in testing, or is there another purpose?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. They are only for testing purposes.

private val pendingChangeNotification = AtomicBoolean(false)
private val lock = ReentrantLock()

private val listeners = ConcurrentHashMap<String, DispatchListener<T>>()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This code does not seem clear enough to me. For instance, can't we use more meaningful names than watchers and listeners?

We might need to review the segmentation in functions to see if the sequence of function names help making the intent of the code clearer...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi David. Watcher is the documented term in the object database API.

Listener is just an event hook for the debugging purposes. Perhaps I'll rename it to eventHook? But listener is more common in Java world. Or perhaps I'll clarify this in comments?

@mikkokar mikkokar merged commit 02e07fc into ExpediaGroup:master Nov 27, 2019
@mikkokar mikkokar deleted the issue-525-object-store-notifications branch November 27, 2019 14:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants